<html>
<head><meta charset="utf-8"><title>rationale behind allocations · t-compiler/const-eval · Zulip Chat Archive</title></head>
<h2>Stream: <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/index.html">t-compiler/const-eval</a></h2>
<h3>Topic: <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/rationale.20behind.20allocations.html">rationale behind allocations</a></h3>

<hr>

<base href="https://rust-lang.zulipchat.com">

<head><link href="https://rust-lang.github.io/zulip_archive/style.css" rel="stylesheet"></head>

<a name="206069705"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/rationale%20behind%20allocations/near/206069705" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jason Hu <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/rationale.20behind.20allocations.html#206069705">(Aug 05 2020 at 19:49)</a>:</h4>
<p>to my knowledge, allocations are used to represent a piece of static data. one question I have been wondering for a while is that why allocation carries concrete bits and bytes other than some abstract representation of the data? wouldn't this break abstraction? in particular, given allocation, there really isn't an alternative way to represent data in any other bit pattern, is there?</p>



<a name="206109893"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/rationale%20behind%20allocations/near/206109893" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Notification Bot <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/rationale.20behind.20allocations.html#206109893">(Aug 06 2020 at 06:55)</a>:</h4>
<p>This topic was moved here from <a class="stream-topic" data-stream-id="182449" href="/#narrow/stream/182449-t-compiler.2Fhelp/topic/rationale.20behind.20allocations">#t-compiler/help &gt; rationale behind allocations</a> by <span class="user-mention silent" data-user-id="124288">oli</span></p>



<a name="206110166"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/rationale%20behind%20allocations/near/206110166" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> oli <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/rationale.20behind.20allocations.html#206110166">(Aug 06 2020 at 07:00)</a>:</h4>
<p>The <code>Allocation</code> is the abstract representation. If you are looking for a better representation for constants used in the type system, we're working on that under the "valtree" keyword: <a href="https://github.com/rust-lang/rust/issues?q=is%3Aissue+is%3Aopen+valtree">https://github.com/rust-lang/rust/issues?q=is%3Aissue+is%3Aopen+valtree</a></p>



<a name="206113641"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/rationale%20behind%20allocations/near/206113641" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/rationale.20behind.20allocations.html#206113641">(Aug 06 2020 at 08:01)</a>:</h4>
<p>(this might actually be a UCG question)</p>



<a name="206113671"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/rationale%20behind%20allocations/near/206113671" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/rationale.20behind.20allocations.html#206113671">(Aug 06 2020 at 08:01)</a>:</h4>
<p>In Rust, I am pushing for (and so far everyone went along) an approach where data in memory is <em>untyped and unstructured</em>, realized as bytes</p>



<a name="206113737"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/rationale%20behind%20allocations/near/206113737" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/rationale.20behind.20allocations.html#206113737">(Aug 06 2020 at 08:02)</a>:</h4>
<p>(though a "Rust Abstract Machine Byte" is <a href="https://www.ralfj.de/blog/2019/07/14/uninit.html">a bit different</a> from a "hardware byte")</p>



<a name="206113761"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/rationale%20behind%20allocations/near/206113761" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/rationale.20behind.20allocations.html#206113761">(Aug 06 2020 at 08:02)</a>:</h4>
<p>the slogan is that <em>memory is untyped, but memory accesses are typed</em></p>



<a name="206113792"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/rationale%20behind%20allocations/near/206113792" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/rationale.20behind.20allocations.html#206113792">(Aug 06 2020 at 08:03)</a>:</h4>
<p>that makes the semantics of low-level code that directly works with the underlying representation of run-time data much more straight forward</p>



<a name="206113819"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/rationale%20behind%20allocations/near/206113819" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/rationale.20behind.20allocations.html#206113819">(Aug 06 2020 at 08:03)</a>:</h4>
<p>this is in contrast to C where memory is very structured and "typed" in various ways, leading to an <em>enormously complicated</em> memory model (which I think has not been fully written down formally ever, so far, but various good approximations exist)</p>



<a name="206113889"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/rationale%20behind%20allocations/near/206113889" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/rationale.20behind.20allocations.html#206113889">(Aug 06 2020 at 08:04)</a>:</h4>
<p>the Miri engine, powering CTFE and <a href="https://github.com/rust-lang/miri/">Miri the tool</a>, is a direct implementation of this part of the (nonexistent) Rust spec</p>



<a name="206113929"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/rationale%20behind%20allocations/near/206113929" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/rationale.20behind.20allocations.html#206113929">(Aug 06 2020 at 08:05)</a>:</h4>
<p><span class="user-mention" data-user-id="320010">@Jason Hu</span> ^</p>



<a name="206155639"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/rationale%20behind%20allocations/near/206155639" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jason Hu <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/rationale.20behind.20allocations.html#206155639">(Aug 06 2020 at 15:19)</a>:</h4>
<p>I don't understand the part in which we would prefer an untyped constant. I don't really see that as a simplification, because effectively that determines the concrete layout of all types already, doesn't it? I have fallen into the problem of Rust type layout has been too concrete to write an alternative backend which does slightly different from the default behavior of the rust compiler.</p>



<a name="206156427"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/rationale%20behind%20allocations/near/206156427" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/rationale.20behind.20allocations.html#206156427">(Aug 06 2020 at 15:25)</a>:</h4>
<p>what I said is not specific to constants at all, it's how the langauge works in general</p>



<a name="206156493"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/rationale%20behind%20allocations/near/206156493" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/rationale.20behind.20allocations.html#206156493">(Aug 06 2020 at 15:25)</a>:</h4>
<p>the entire <em>point</em> is that all backends have to do this in a very similar way. if backends were allowed to differ, then code that works fine on one backend would break on another.</p>



<a name="206156635"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/rationale%20behind%20allocations/near/206156635" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/rationale.20behind.20allocations.html#206156635">(Aug 06 2020 at 15:26)</a>:</h4>
<p>as for constants, once they are done valuation, their final <em>result</em> can and should be converted into a higher-level representation when it is relevant for the compiler itself. when it is just used by the program, we simply dump the final allocation into the binary and call it a day.</p>



<a name="206200762"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/rationale%20behind%20allocations/near/206200762" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jason Hu <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/rationale.20behind.20allocations.html#206200762">(Aug 06 2020 at 21:44)</a>:</h4>
<p>I understand that eventually all constants are converted to bits at the end of the day. this is a compiler does after all. like you said,</p>
<blockquote>
<p>once they are done valuation, their final result can and should be converted into a higher-level representation when it is relevant for the compiler itself</p>
</blockquote>
<p>my problem is, Allocation shows up in MIR which I think should be decoupled with whatever backend to feed into. The fact that Allocation is in MIR determines there is only one bit pattern for each constant, namely that is not very high level. for example, if I want to use only tagged unions to represent enums, I am pretty much doomed, aren't I?  Or otherwise, is there a way to convert an allocation back to something a bit more high level?</p>



<a name="206228696"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/rationale%20behind%20allocations/near/206228696" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> oli <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/rationale.20behind.20allocations.html#206228696">(Aug 07 2020 at 06:52)</a>:</h4>
<p><span class="user-mention silent" data-user-id="320010">Jason Hu</span> <a href="#narrow/stream/146212-t-compiler.2Fconst-eval/topic/rationale.20behind.20allocations/near/206200762">said</a>:</p>
<blockquote>
<p>for example, if I want to use only tagged unions to represent enums, I am pretty much doomed, aren't I?  Or otherwise, is there a way to convert an allocation back to something a bit more high level?</p>
</blockquote>
<p>If you change the enum representation this late in the process you're already in trouble. The only place you are allowed to change enum representation is in the <code>layout_of</code> query. Changing the representation anywhere else will break compilation in horrible ways. Simple example: <code>size_of</code> of the enum type will differ between the way you represent the enum and the way rustc represents it. So any user code using <code>memcpy</code> or any other untyped operation just using the size will see a different picture from what you're seeing.</p>



<a name="206228713"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/rationale%20behind%20allocations/near/206228713" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> oli <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/rationale.20behind.20allocations.html#206228713">(Aug 07 2020 at 06:53)</a>:</h4>
<p>if you do change <code>layout_of</code>, the mir interpreter will automatically pick up those changes and actually compile constants in the correct bit pattern logic for your backend</p>



<a name="206232634"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/rationale%20behind%20allocations/near/206232634" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/rationale.20behind.20allocations.html#206232634">(Aug 07 2020 at 08:05)</a>:</h4>
<p><span class="user-mention" data-user-id="320010">@Jason Hu</span> you still seem to conflate what an allocation is in MIR with how a constant is evaluated, so I am not even sure what you are asking here.</p>



<a name="206232712"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/rationale%20behind%20allocations/near/206232712" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/rationale.20behind.20allocations.html#206232712">(Aug 07 2020 at 08:06)</a>:</h4>
<p>An allocation in MIR is just a bunch of bytes. That's how Rust works, it's how LLVM works, it's unlikely we are going to change something as fundamental as that. Sure, it has not been officially ratified by an RFC yet, but it's what <a href="https://github.com/rust-lang/unsafe-code-guidelines/">the UCG WG</a> has been working with as well.<br>
This fact has nothing to do with constants.</p>



<hr><p>Last updated: Aug 07 2021 at 22:04 UTC</p>
</html>